Allow Wildcard Subdomain

(QW.AllowWildcardSubdomain, QW.AllowDnsSuffixMatch)

Overview

This is a private feature developed by Qwilt.

This feature can be configured at the site or host level.

Enable Wildcard Subdomain to apply host configuration settings to host subdomains as well. Rather than configuring a host for each subdomain, you can define a single host configuration that automatically applies to all matching subdomains.

For example, if a host is configured as example.com and this feature is enabled, requests to www.example.com, media.example.com, or any.other.subdomain.example.com would all match this host configuration. If disabled (the default), only requests explicitly matching example.com would be served.

Note that this feature is not supported for HTTP routing.

info

This feature uses the QW.AllowWildcardSubdomain feature type. A previous version used the type QW.AllowDnsSuffixMatch, which is still supported for backward compatibility but should not be used for new configurations.

Example

In this example, wildcard subdomain is enabled:

{
  "generic-metadata-type": "MI.PrivateFeature.Qwilt.QW.AllowWildcardSubdomain",
  "generic-metadata-value": {
    "enable": true
  }
}

Supported Properties

Field	Valid Values	Description	Default
enable	true, false	Enables or disables wildcard matching.	false

Configure Custom Behavior for a Particular Subdomain

To configure different behavior for a particular subdomain, configure an additional site host for that subdomain. Explicit hostnames take precedence over Wildcard Subdomain.

In this example, although d.example.com is a subdomain of example.com, the CDN will not treat it as a match for example.com because d.example.com is explicitly defined as its own site host. As a result, requests to d.example.com are processed according to the host configuration settings defined for d.example.com.

{
  "host": "example.com",
  "host-metadata": {
    "metadata": [
      {
        "generic-metadata-type": "MI.PrivateFeature.Qwilt.QW.AllowWildcardSubdomain",
        "generic-metadata-value": {
          "enable": true
        }
      }
    ],
    "paths": []
  }
},
{
  "host": "d.example.com",
  "host-metadata": {
    "metadata": [],
    "paths": []
  }
}

Allow Some, But Not All Subdomains

By default, all Wildcard Subdomains are allowed. To allow only specified subdomains and not all subdomains, you can configure a Client Request Access rule to create a match condition.

In this example, the match expression creates a host allow list. Only the subdomains specified in the allow list are covered by Wildcard Subdomain. It allows requests only if the Host header matches x.example.com, y.example.com, or z.example.com. Requests with any other Host value are denied with a 403 response.

{
  "host": "example.com",
  "host-metadata": {
    "metadata": [
      {
        "generic-metadata-type": "MI.ProcessingStages",
        "generic-metadata-value": {
          "client-request": [
            {
              "stage-metadata": [
                {
                  "response-transform": {
                    "synthetic": {
                      "response-status": "403"
                    }
                  }
                }
              ],
              "match": {
                "expression": "not(req.h.host~='x.example.com' or req.h.host~='y.example.com' or req.h.host~='z.example.com')"
              }
            }
          ]
        }
      },
      {
        "generic-metadata-type": "MI.PrivateFeature.Qwilt.QW.AllowWildcardSubdomain",
        "generic-metadata-value": {
          "enable": true
        }
      }
    ],
    "paths": []
  }
}

Cache Keys

By default, when Wildcard Subdomain is enabled, all subdomains share a single cache key. Likewise, configuring a basic Cache Key Management rule results in shared cache keys across subdomains.

To produce a unique cache key for each subdomain, you can configure an advanced Cache Key Management rule.

In this example, the hostname req.h.host is included in the cache key, creating distinct cache keys for each subdomain.

{
  "host": "example.com",
  "host-metadata": {
    "metadata": [
      {
        "generic-metadata-type": "MI.SourceMetadataExtended",
        "generic-metadata-value": {
          "sources": [
            {
              "protocol": "https/1.1",
              "endpoints": [
                "www.example.com"
              ]
            }
          ]
        }
      },
      {
        "generic-metadata-type": "MI.ComputedCacheKey",
        "generic-metadata-value": {
          "expression": "req.h.host . '&' . req.uri.path"
        }
      },
      {
        "generic-metadata-type": "MI.PrivateFeature.Qwilt.QW.AllowWildcardSubdomain",
        "generic-metadata-value": {
          "enable": true
        }
      }
    ],
    "paths": []
  }
}

In short, to create a unique cache key for each subdomain, configure an advanced cache key rule with a MEL expression that includes the req.h.host element.

The MEL expression for a cache key, req.h.host . '&' . req.uri.path, uses the entire request path and considers the request host header.

In this example, because the host configuration enables Wildcard Subdomain, requests URLs for 1-example.com/path/to/file and 2-example.com/path/to/file would each generate a distinct cache key.

Or, to share a cache key across subdomains, exclude the hostname from the MEL expression: 'example.com&' . req.uri.path

In this example, requests to 1-example.com/path/to/file and 2-example.com/path/to/file would generate the same cache key.

MEL Quick Reference

Site Certificate

Make sure to configure your site certificate in a way that covers all the hosts and wildcard subdomains.

You can achieve this by:

• Creating a wildcard certificate.
• Creating a multi domain certificate.

Certificate Management

Purge

When Wildcard Subdomain is enabled:

• Purge by Site - covers all hosts and subdomains.
• Purge by Prefix - covers all hosts and subdomains.
• Purge by URL - covers the selected host and its subdomains.

Purge